Skip to content

WeBWorK 2.21 Release Candidate#2940

Open
drgrice1 wants to merge 392 commits into
mainfrom
WeBWorK-2.21
Open

WeBWorK 2.21 Release Candidate#2940
drgrice1 wants to merge 392 commits into
mainfrom
WeBWorK-2.21

Conversation

@drgrice1

Copy link
Copy Markdown
Member

This is the release candidate for WeBWorK 2.21. Please re-target any pull requests that you want to get into the release for this branch.

Alex-Jordan and others added 30 commits December 23, 2025 14:33
Remove Cosign authentication module
prompt email recipient to use reply-all when there were multiple reci…
The packages and TikZ libraries that are used by pg are all tested
(including the TikZ spath library that is going to be used once
openwebwork/pg#1336 is merged).

Note that the "active" option was removed from the preview package in
the check_latex_article.tex and check_latex_exam.tex files because that
suppresses output.  It is enough to test that the preview package loads,
and this makes the more important things that are being tested more like
they are for actual hardcopy generation and not for equation generation.
We really need to remove images mode.
Add a standalone variant to check_latex.
Add option to allow the `allow_unsecured_rpc` option to be a hash
of course ids, which can be set to 0 or 1 to disable cookies only
for that course. Further, the course id could also be a hash of
user ids that can be set to 0 or 1 to disable cookies only for the
specified user id.
Fix a potential XSS vulnerability on the hardcopy page.
This adds the PG critic results from `WeBWorK::PG::Critic` to the PG
problem editor.  Note that the "Format Code" tab in the editor is now
the "Code Maintenance" tab.  This is because this new option is not a
code formatter.  All of the options fit into the category of code
maintenance, so this is a better name.
Translate the feedback email templates.
Configure rpc endpoints to disable cookies for specific courses/users.
Add "PG Critic" to the PG problem editor.
enhanced subject line formatting options for email
…e unanswered.

When the "Grade Test" button is clicked, JavaScript parses the
`probstatus` inputs and determines what problems are in the test. Then
it finds the answer inputs in the page and determines if there are any
questions in a problem that are unanswered.  If there are any problems
with unanswered questions, then a message stating that is added to the
confirmation dialog.

This is to address the feature request in issue #2183.

Generally, this will work for most answers.  However, there are a couple
of cases that don't work right.  These are cases where answer inputs are
non-empty even if a student has not actively entered an answer.

Most notable is the case of an answer to a `draggableProof.pl` or
`draggableSubset.pl` question. The JavaScript for those always fills in
a non-empty answer as soon as the problem is loaded into the page.

Another case is if a problem uses the deprecated `PopUp` method from the
`parserPopUp.pl` macro or the deprecated methods from
`PGchoicemacros.pl`.  For example, if `PopUp([ '?', 'a', 'b', 'c' ], 1)`
is used.  That will have the non-empty value `?` for the default answer.

Unanswered questions that use the `draggableProof.pl` and
`draggableSubset.pl` macros could be determined server side, but the
only way to do so would be to process the problem via PG.  There were
several suggestions in issue #2183 to use a server side set "flag" or
have other server queries involved in this.  Those really don't help
other than in this case, and generally shouldn't be done.  We really do
not want to have a submission to the server that processes all problems
in a test to determine if there are unanswered questions before
submitting a test for grading in which all problems will again be
processed.  There was a suggestion to change the "preview test" button
into a "save answers" button, but even that doesn't really help.  It
would not be reliable, because the information would only be there if
the button were used first. There is no guarantee it would be used
first, and this needs to have the ability to process the answers
regardless.

Note that attempting to correctly determine if a question that uses
`parserPopUp.pl` or `PGchoicemacros.pl` is unanswered cannot even be
done by processing the problem.  This just adds emphasis that those
should not be used anymore.

There may be some other cases that have non-empty answers without
students actively answering a question, but I can't think of any at this
point.

One thing to note is that if a problem has never even been displayed on
the page (for example a `draggableProof.pl` problem that is on a page of
the test the student never goes to) this approach will work correctly
even for the above cases.
Add a message to the grade test confirmation dialog when questions are unanswered.
Add message to PG critic output if no issues are found.
This module is broken and I am rather certain it can't even be fixed.
It uses an archaic and rather unsecure approach of trying to read
cookies from Moodle and using that for authentication. In most cases
this would be a cross domain cookie and most likely impossible to read.
This approach might have worked a long time ago, but cookie's have
changed a lot since then.
Remove the Moodle authentication module.
Remove the `Plots::GD` PG module dependency.
This deletes the course map entry for the course's previous name, and
then creates a new entry for the course's new name.

Since the `renameCourse` method is also used when unarchiving a course
to a different name, care needs to be taken to ensure that this is only
done for a course rename, and not for that situation. Thus there is a
new `updateLTICourseMap` option for the method.  This is only true when
the method is called to rename a course directly.

This addresses issue #2824.
…link_uri.

This is useful if you want to make unpublished instructor links in the
LMS that go to specific pages in webwork with query params to make
certain display options active immediately.  For example, if you use a
link such as
`https://webwork.server.edu/webwork2/instructor/progress/set/setID?returning=1&show_date=1&show_testtime=1&show_problems=1`
then the test dates, times, and problems will be shown when the page
opens.

Currently URL parameters are dropped.  This was not intentional when I
implemented this, it is merely a side effect of calling `systemlink` and
`url_for` on the `target_link_uri` that is given.

This just gets the query parameters that are passed in the given
`target_link_uri` and then passes them to `systemLink` so that it adds
them back to the generated URL that gets redirected to.
… generation.

First, there are some minor tweaks to the POD and sample problem viewers:

* Fix the wording on the sample problem viewer index page for "Sample
Problems by Macro".  It current says, "For many macros, this lists all
sample problems used by the macro."  However, macros do not use sample
problems.  Sample problems use macros.  So the wording is now, "For many
macros, this lists all sample problems that use the macro."

* Update the version of bootstrap in the POD templates to 5.3.7 which is
currently the latest.

* Update the links in the pod templates to wiki.openwebwork.org.

* Remove the `favicon` links.  Those are not explicitly needed.  Browser's
now load the favicon even if the page does not contain the link. The
link only needs to be added if the file is not named favicon.ico.

The following are the actual changes needed to accomodate changes to the
PG POD and sample problem generation:

* Remove files that are now used from the PG repository.

* Remove the PODViewer js and css files, the PODParser.pm and PODtoHTML.pm
modules, and category-index.mt and pod.mt templates, all of which are
now provided by PG.

* Make the necessary changes to the generate-ww-pg-pod.pl script so that
it can use those files from the PG repository.

* Update the SampleProblemParser module usage for its changes and
namespace change.

* The `WeBWorK::PG::SampleProblemParser` module now handles generation of
the actual search data with its `getSearchData` method.  So the
`WeBWorK::ContentGenerator::SampleProblemViewer` just calls that method.

* The `assets/stop-words-en.txt` file is now in the PG repository so that
the `WeBWorK::PG::SampleProblemParser::getSearchData` method can get at
it easily.

* The `htdocs/js/SampleProblemViewer/documentation-search.js` file is now
in the PG repository, and webwork2 uses it from there.  PG also copies
it to the PG docs github pages site in its new workflow. The options are
passed in via the script in `templates/ContentGenerator/SampleProblemViewer.html.ep`.
drgrice1 and others added 30 commits May 27, 2026 05:16
Lockfile version 3 has been supported since node version 18 (and npm
version 7).  So there is no need to stay with lockfile version 2
anymore. The only real change it seems is that the `dependencies`
section is removed. This means that the file is about 1500 lines
shorter!
Remove the `CAPA_Graphics` link.  I missed this when everything else
CAPA related was removed before.  (grep doesn't show it!)

Also remove the `crossdomain.xml` file.  I don't think this is not used
with the current approaches for serving webwork2, and if it is, it is
most likely a security vulnerability.
Fix an invalid import that is causing warnings.
Switch `package-lock.json` to lockfile version 3.
Minor clean up in the htdocs directory.
The JavaScript needs to not attempt to do anything with the
`add_on_conf` select if it is not present in the page, as that causes
errors. For instance if the `$webworkDirs{addOnConf}` directory is not
present, or is empty.

With modern JavaScript, don't use the array `forEach` method unless it
gives a convenient and brief one liner.  Generally prefer a `for of`
loop as it is more readable. Another advantage is that `for of` loops
work on `HTMLCollection`s and `forEach` does not.  The result of a
`querySelectorAll` call or the `children` of an `Element` are
`HTMLCollection`s, and so a `for of` loop works directly, while
`Array.from` is needed to use `forEach`. This is a minor inefficiency in
this case, but that does require constructing an array from the
`HTMLCollection`.

I rewrote the `writeCourseConf` POD to clarify its usage some with the
new optional parameter.

In the `writeCourseConf` method, it should be checked that the
`$addOnConf` variable is an array reference, and not that it is not
equal to the empty string. Any numeric value or non empty string is not
equal to the empty string and would cause an error if `$addOnConf` is
set to any of those.  The check should be that `ref $addOnConf eq 'ARRAY'`.
That is the only condition that guarantees an error will not occur and
that the value of the variable will work inside the conditional block.

Minor cleanup in the `templates/ContentGenerator/CourseAdmin/add_course_form.html.ep`
file. There is no need to copy the value of `$ce->{webworkDirs}{addOnConf}`
to a local variable.  Particularly since that can be used directly even
in string interpolation.
See issue #2955 for details.  This is just the code suggested by @dpvc
in that issue.
Fix the issue with MathJax rendering when certain fonts are used.
…ersion_list.html.ep`,

and fix a minor issue with the remaining time shown for tests when
viewing the test information page and a timed test is in progress.
…ourse.

The errors in the error list that message is added to are html escaped,
and so it can not contain html.  The errors could be prevented from
being escaped, but I see no reason to do so for that one message. None
of the much more important errors added to that list use html.  This
particular message will almost never be seen unless a user is manually
editing the URL with an incorrect subDisplay parameter.
This is something that Google Chrome's Lighthouse and other
accessibility checkers now complain about.

Also add the `nav` and `footer` landmark on a couple of pages.
…ownload.

When the "Archive Course" button in the "File Manager" is used, the
course archive is generated in a temporary directory in the root of the
course directory.  That file is then immediately offered for download,
and deleted as soon as the request is completed.

This is as discussed in issue #2983.
…lem.pm` package.

Currently if the `modify_problem_sets` permssion level is set to "ta",
then a "ta" user can use the problem editor.  However, if the user
selects "Open in a new window" with a different seed than is set in the
database for that user or has made local edits saved to a temporary
file, then the problem will initially render with that seed and
temporary file, but if the "Check Answers" button is used the problem
reverts to using the user's seed and source file for the problem from
the database.  This is because the package is inconsistent on the
permissions conditions that it uses.  When the problem to render is
selected in initialization the `modify_problem_sets` permission is used.
However, when it is deteremined if the `sourceFilePath` and
`problemSeed` parameters can be hidden in the form, it is checked
instead that the user has the "professor" permission level.

To fix this those checks need to be made consistent.  The "professor"
permission level check was incorrect, and the `modify_problem_sets`
permission should be used instead.

This fixes issue #746. Webwork2's oldest open issue!
…r in dark mode.

The `bg-white` class is set for the containing panel for the view area
in the PG editor.  So for the text to be dark so that it works even in
dark mode.

This is the quick and easy fix.  Better probably would be to use a
color scheme responsive class such as the `bg-light` class (as is done
for course info files). Then in dark mode you would get a dark
background with light colored text.  However, that would change the
background color in light mode.  Currently the background is actual
white in light mode, and the `bg-light` class is an off white (same as
the background of the site navigation).
…anager.

Currently the sort methods are called with the ampersand sigil.  That
implies the argument of `@_` and with recent versions of Perl that
causes the warning `Implicit use of @_ in subroutine entry with
signatured subroutine is experimental`.

This exact same issue was fixed for the accounts manager page in #2607,
and this is the same thing exactly and fixed in the same way.
Well, @somiaj has at least.  If you have your window size set to exactly
the breakpoint (which is 768 pixels), then the site navigation will not
open.  The `=` needs to be on the other side of the check in
`htdocs/js/System/system.js`.
Using `left: -20%` seems to not be working well at small window widths
just above the break point.  Using `left: 250px` which exactly matches
the sidebar width seems to work better.  With `left: -20%` the
problem/student nav looks like it is moving to the left to fast.
Fix a major bug with the navigation that everyone has certainly seen.
Add a `main` landmark to pages.
Some odds and ends that I have had sitting here for a couple of years now.
Fix a warning due to the way the sort methods are called in the job manager.
Fix contrast when viewing the xml of a hardcopy theme in the PG editor in dark mode.
…vlem-view

Make permissions for viewing an edit file consistent within the `Problem.pm` package.
…wnload

Make the course archive generated via the file manager an immediate download.
Suggested clean up and minor issue fixes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants